In communication systems, a transponder receives and amplifies incoming signals, for example, an incoming signal from a satellite, and retransmits the amplified signal on a different frequency. With data compression and multiplexing, several video and audio channels may travel through a single transponder.
The output of the transponder is connected to a tuner for decoding. The tuner receives the output of the transponder and converts the output, having a different frequency, into a form suitable for processing. The output of the tuner is, for example, used by a synchronizer to establish the boundaries of the incoming data. After synchronization, markings establishing the boundaries of the incoming data are forwarded with the data to further modules. A transport packet arbiter and router is provided to handle multiple synchronized data packets from the synchronizer.
In a Digital Video Broadcast (DVB) system, for example, a transport stream is output by a transponder and decoded by a tuner. The transport stream typically includes packets of constant size to facilitate the addition of error-correction codes and interleaving in a higher layer. Each packet is 188 bytes long. The format of a transport packet is shown in FIG. 1.
The transport stream packet begins with a header of 4 bytes. The remainder of the packet carries data known as the payload. The first byte of the header is a sync byte and has a unique pattern represented by a predetermined bit pattern, for example, 0×47 (hexadecimal) i.e. 0100 0111 (binary).
The incoming transport stream is asynchronous to the DVB system, requiring the DVB system to synchronize the transport stream. Synchronization means are necessary for identifying the sync byte 0×47, and then establishing the boundaries of a packet by gathering 188 bytes including the sync byte.
In an application where multiple transponders with multiple tuners are present, each tuner output and hence each transport stream needs to be synchronized before being routed to its destination. A conventional multiple tuner transport stream synchronization system 200 is shown in FIG. 2. Note that in FIG. 2 and subsequent figures, multiple instances of an identical module are labelled with letter suffixes. Use in this description of the label without the letter suffix refers to any one of the identical instances of the corresponding module.
In the conventional multiple tuner transport stream synchronization system 200, the output of each transponder 210 is connected to a corresponding tuner 220 to extract the transport stream. The output transport stream of a tuner 220 is connected to a synchronizer 230 for synchronization before being routed to its destination by a transport packet arbiter and router 240.
The transport packet synchronizer 230 identifies the sync byte 0×47 and establishes the packet boundaries.
Difficulties may arise in the detection of the sync byte 0×47 of a packet when the payload contains data matching a 0×47 byte.
FIG. 3 shows a snapshot of a transport stream of incoming data from the tuner 220 to the transport packet synchronizer 230. FIG. 3 illustrates a scenario where bytes other than the sync byte in the packet are 0×47. As the start of a packet is not inherently identified, the correct sync byte 0×47 needs to be captured from this stream. An occurrence of 0×47 may represent the actual sync byte of the header or may represent a part of the payload data. Differentiating between the sync byte 0×47 and normal data 0×47 is not possible based on a single identified occurrence of 0×47. Synchronization is identified by detecting a repetition of 0×47 every 188 bytes.
For example, an attempt to synchronize the transport stream of FIG. 3 first identifies byte 0 as matching the sync pattern 0×47. The remaining 187 bytes are then counted to identify the transport packet boundary. If byte 0 were a proper sync byte, the second packet would start at byte 188 with another sync byte 0×47. As shown in FIG. 3, however, the 188th byte has a data of 0×22. In this manner, it is determined that the first occurrence of 0×47 is not a sync byte. Another occurrence of a sync pattern is therefore searched for. It should be noted, however, that the second occurrence of the sync pattern 0×47 occurring at byte 1, which in this scenario was an actual sync byte, has already been lost while counting the incoming data for the first occurrence of 0×47. Therefore, only the next occurrence of the sync pattern 0×47, after 188 byte from the first occurrence of 0×47 have been counted (ie. byte 189), can be identified. If the next identifiable occurrence of 0×47 is again not a sync byte, the process is repeated. Synchronization of a transport stream may therefore take a long time. Until the transport stream is synchronized, further processing cannot be performed. In some cases synchronization may never be achieved.
The logic for a conventional synchronizer is typically complex and large, occupying a large amount of silicon area. In silicon area critical applications it becomes difficult to fit the conventional logic shown in FIG. 2 alongside other logic blocks. Further, once synchronization is achieved, the synchronizer is idle for most of the time.
There is a need for a more efficient usage of logic to synchronize the transport stream from multiple transponders/tuners.